Instead of ignoring it, I go down the rabbit hole.

AI agents have made this much worse.

When your agent can crawl across Slack, GitHub, Linear, Snowflake, Notion, and your local files, those nagging questions that never had answers before are suddenly just a query away. I can fire one off and get a detailed recollection across surfaces: the first time someone mentioned an idea, the first ticket in Linear, the first commit in GitHub, and the first launch update in Slack.

It feels incredibly productive. It feels like embracing curiosity and using newfound leverage to investigate more and move faster than I ever could before.

Clearly this is the future, right? This is how you get 10x leverage and get ahead?

I’ve also been noticing something else: a kind of low-grade exhaustion I can’t pinpoint.

I’m not overworked. If anything, I delegate a large portion of what I do. A surprising amount can be done from my phone using voice mode while I go for a walk. I have more capacity than ever to start things and feel less restricted than ever.

Yet it all still feels tiring. I end some days drained. Sometimes I have a hard time sleeping and can’t explain why.

Agents aren’t doing work for free

When you fire off an agent, you get the reward upfront.

You see it thinking and calling tools. You feel progress. Your dopamine starts buzzing as you imagine how long the same query would take manually, crawling through hundreds of thousands of lines of text across several systems.

You just did 100x the work for almost no effort.

Except it wasn’t free. You signed yourself up for work on the backend.

You need to validate the result. You need to imagine where hallucinations or bad assumptions could have entered. When it returns, you have to context-switch back into the thread, leaving attention residue that makes it harder to resume whatever you were doing before.

You’re paying a tax you didn’t see at the time of purchase because the purchase felt free.

It’s also not just you prompting the agent. The agent is prompting you.

Every result surfaces another thread to pull, another question, or a new “interesting” direction to investigate. The tool is generating tremendous amounts of work for you, and you’re absorbing it because it did so much for you.

AI reduces the cost of starting work. It does not reduce the cost of deciding what deserves your attention. In many cases, it increases it.

This is a control loop problem

When you design an AI agent, you define success criteria, guardrails, and limits on what it should pursue. You give it an objective and explicit non-objectives. You control what tools it can access and what it can change. You cap how long it can iterate before it must commit, stop, or check in.

Without those constraints, an agent will chase tangents, clutter its context window, and produce shallow work that misses your point.

AI power users naturally learn to do this for their agents. Most never think to build the same guardrails for themselves.

I certainly took too long to do it.

What I realized is that I need my own control loop: something that keeps me from spreading my attention too thin, limits the number of concurrent threads I allow, and forces me to measure impact rather than activity.

Luckily, the principles already exist. Cal Newport has written about them extensively in books like Deep Work and Slow Productivity. In the AI agent era, I think they matter even more.

Newport’s principles aren’t productivity hacks. They’re design specifications for the human control loop.

Do fewer things: limit concurrent threads

This is work-in-progress limiting.

Giving an agent several objectives at once increases the likelihood that it will drift or make mistakes. The same is true for you. Every agent you fire off and every thread you open is a claim on your future attention.

An agent “working in the background” is not actually out of mind. Some part of you is tracking that it will return and reserving capacity to evaluate it.

The fix is restraint: place a hard cap on how many concurrent threads you allow yourself to have open. This comes from the same logic as a Kanban WIP limit. Limiting work in progress improves flow through the whole system, even when every individual task feels cheap to start.

Work at a natural pace: govern iteration

AI creates real acceleration. It also creates the artificial sensation of it.

Results that once took hours can return in minutes. Every response surfaces new things to chase. There is no natural pause where you would otherwise decide, “This is enough. I need to move on.”

You need an explicit governor on how long you allow yourself to pursue something before you commit, stop, or put it somewhere for later.

Maybe that is a time block. Maybe it is a fixed number of iterations. Maybe the rule is, “I’ll create three variants and choose among them using criteria I defined before I started.”

This is exactly the stopping condition you would give an agent to prevent an endless loop. The difference is that you have to respect it yourself.

Measure impact, not output

Cal Newport calls it pseudo-productivity: measuring visible activity instead of meaningful results.

AI amplifies this because every query produces something that looks substantial. A sourced timeline or research report feels like serious work even when it did not advance anything that matters.

I still run exploratory prompts, but I try to anchor them in a question that informs a real decision. What will I do differently based on what I find? What uncertainty am I trying to reduce? What should exist when the loop closes?

If I can’t answer those questions, I should question whether I need another multi-stage agent run with five sub-agents and a research report.

A planning system with rules I actually follow

None of this works if it remains a set of ideas. You need a system that enforces the human control loop in practice, just as skills, permissions, tests, and stopping conditions constrain an agent.

I’ve been piloting a multi-scale planning system influenced by Newport’s work. It lives primarily in Notion, with Google Calendar as the source of truth for time. I operate it through Codex and Claude Code, which can read the relevant surfaces, prepare a briefing, and execute updates after I approve them.

The most important design decision is also the least magical:

The agent does not decide what I’m committed to.

It gathers evidence, shows me tradeoffs, and maintains the machinery. I choose what enters this week, what enters today, what I am waiting on, and what deserves calendar time.

Kanban as a commitment limit

I center the system around a simple Kanban board. It is not an endless task list. It is a visible constraint on what is allowed to occupy my attention.

The flow is:

• Inbox: Unprocessed items that may or may not become real work.

• Clarify: Work that might matter but is not shaped enough to act on.

• Backlog: Understood work I want to retain but have not committed to.

• This Week: Work I explicitly selected for the week.

• Today: The small set I explicitly pulled into the day.

• Waiting: Work blocked on another person or event.

• Done: Work I completed.

• Dropped: Work I deliberately decided not to pursue.

Done and Dropped stay separate because their histories answer different questions: What did I finish, and what did I consciously prune? Over time, the split shows whether I am completing selected work or accumulating commitments I later reject.

Interesting thoughts usually start in the Capture Buffer, not on the board. They earn an Inbox card only when there is a real action or obligation to evaluate. Once on the board, the status records my actual decision: shape it, retain it, commit to it, or wait on a dependency.

I also use hard caps. Today can contain at most one deep item and two shallow items. This Week can contain at most seven cards serving three outcomes. Clarify is capped at five.

Those numbers are not mathematically perfect. They are a governor. When something new wants to enter, I have to decide what moves out.

That tradeoff is the point.

A capture buffer that interrupts the interruption

As I work, interesting ideas and side quests appear. Many do not deserve a Kanban card. The temptation is to act immediately because the cost is now so low. I can dictate a prompt and have an agent halfway down the rabbit hole before I consciously decide whether the question matters.

Instead, I put the thought in a dedicated Capture Buffer in Notion.

This is my scratch space. Agents never add things to it. An inbox generated by agents would become another feed demanding my attention. The point is to externalize my interrupts, not manufacture new ones.

During shutdown, the agent walks through each unprocessed line with me. I choose whether to turn it into an Inbox card, preserve it as a durable note, do both, or drop it. The agent marks it processed but does not silently promote it into Today or This Week.

I do not have to decide whether an idea matters while it is interrupting me. I only have to capture it. The judgment happens later, on my schedule.

The Capture Buffer does not eliminate curiosity. It interrupts the interruption.

Morning planning as a bounded decision

Before I start firing off agents, I plan the day.

Codex or Claude Code reads the weekly plan, reviews the live calendar, and inspects the cards already selected for This Week or Today. It gives me a realistic picture of capacity and asks me to choose the intended win.

Then we pull at most one deep item and two shallow items into Today and shape the calendar around them.

This is different from asking an assistant, “What should I do today?” The agent is not inventing priorities from everything it can see. It is helping me make one decision from an already constrained set of commitments.

On one meeting-heavy day, the system did not generate an aspirational list of seven things. It identified two short prep windows and helped me choose one intended win: prepare sharp questions and initial hypotheses for a 2:30 product meeting.

I still deviate from the plan. Frequently. The plan gives those deviations a reference point. I can tell the difference between consciously changing direction and merely drifting.

Shutdown closes the loops agents opened

At the end of the day, the agent helps me capture loose obligations, route the Capture Buffer, reconcile Today, update waiting work, and review tomorrow’s calendar.

For active work, I leave a restart note: current state, next concrete action, what to open first, and any blocker. This converts the day’s residue into state I can resume tomorrow.

One evening, a long prototype and research thread had exposed that a product brief was underspecified. The easy failure mode was to keep building. Instead, shutdown forced the distinction into the open: the prototypes were conversation artifacts, not solution commitments. The next action was to clarify the problem, not add more features.

That was more valuable than another hour of output.

The ritual is also a psychological signal: this block is over. Move on. AI chat will never naturally give you that signal. It will always have another suggestion.

The system has to learn from friction

I do not think you can design the perfect planning system upfront. I certainly did not.

I started with a daily checklist as the main execution surface. In practice, it felt like another place to maintain. I wanted to drag a card into Today and drag it out when I finished. So the board became the day-of interface, and the daily plan became a lightweight record rather than a duplicate task list.

I also experimented with a more elaborate work graph that synthesized activity across systems. It was interesting, but it became another subsystem to reason about. I retired it when it stopped earning its complexity.

A personal control loop can become its own rabbit hole.

The test is not whether the architecture is clever. The test is whether it helps you choose, act, stop, and restart with less friction.

The human is part of the agent system

There is a temptation to describe this as an “AI chief of staff.” That is useful but slightly misleading.

The agent can gather evidence, compare the plan with reality, surface mismatches, maintain state, and make tradeoffs legible. It can remove enormous amounts of clerical and retrieval work.

But it cannot own the setpoint.

You do.

The division of labor is simple:

The agent gathers, briefs, and writes. I decide.

Nothing enters Today, This Week, or Waiting merely because the agent noticed it. Meeting notes do not automatically become obligations. Capture does not become commitment without a decision.

If the agent can launch ten times more work, the operator needs stronger WIP limits. If it can return results in minutes, the operator needs stopping conditions. If it can search every surface, the operator needs a clear question. If it can always suggest another direction, the operator needs a shutdown ritual.

The more capable the agent becomes, the more important the human control loop becomes.

AI gives you more capacity to begin. It does not tell you what is worth finishing.

The goal is not maximum output.

The goal is to direct leverage without letting it direct you.

For most people, that brings to mind factories, lines, queues, bottlenecks, handoffs, throughput, variation, and flow. The discipline was always broader than the factory frame.

At its best, industrial and systems engineering teaches you to see work as a system: people, machines, information, incentives, and constraints interacting over time.

The setting changes, but the same questions persist.

Where does work wait? When does quality break down? Which local optimizations make the whole system worse? Which feedback arrives too late to matter?

The Toyota Production System became an important reference point for that reason. TPS treated flow, quality, waste reduction, and learning as design problems inside the work itself, even outside the factory frame. Quality belonged inside the work, before the final inspection. Learning happened inside the system, close to where problems surfaced and could be corrected.

The Goal became a seminal book for operators for the same reason.

Eliyahu Goldratt made the logic of constraints legible through a factory story: a plant can be full of efficient local activity and still fail when the whole system ignores the constraint.

The lesson was to understand the system well enough to improve flow where it actually mattered.

Then The Phoenix Project carried that inheritance into software.

Software looked different from a factory floor. The work was less visible. The inventory was work in progress. The bottlenecks lived in handoffs, tickets, deployments, incidents, queues, unclear ownership, and feedback loops that were too slow to correct the system.

The operating problem was familiar.

The promise of The Phoenix Project was that IT work could be managed like a production system once you made invisible work visible, oriented teams around flow, amplified feedback, and built continual learning into daily work.

That lineage runs through Agile, DevOps, CI/CD, incident response, platform engineering, and product operations. The agentic AI era carries those principles into a new work system.

Agents change where reasoning can live

Agents matter because they change where reasoning can live.

Historically, if you wanted software to handle a workflow, you had to make the workflow legible to software first. You had to derive the rules, define the fields, map the decision tree, specify the edge cases, and decide in advance where the system should stop.

That works well for stable processes.

Much of real work resists clean rules.

The inputs are messy. The relevant context lives across tools. The judgment changes by case. The edge cases matter. The work is too repetitive to deserve constant human attention, but too ambiguous to encode into traditional software.

So we accepted three bad options: static rules that broke at the edges, heavy process that forced humans to compensate for the software, or no system at all.

Agents change that tradeoff.

You can now place human-like reasoning in parts of a workflow where you previously had to rely on static rules, rigid process, or manual handoffs. An agent can read messy context, inspect logs, run queries, classify an issue, draft a recommendation, modify a codebase, call tools, and escalate uncertainty back to a human.

The human moves to a better part of the loop.

The operator reviews exceptions instead of manually inspecting every case. The analyst guides an agent through root-cause analysis instead of gathering every signal from scratch. The builder creates generalized tools an agent can compose across problems instead of building a brittle workflow for every edge case.

The shift matters because a single operator can now do work that once required a team, a roadmap, and custom software.

The gain has a cost. Add agents to old workflows without changing the operating model, and you get faster motion, hidden decisions, inconsistent artifacts, context rot, and cleanup work disguised as progress.

Leverage Loops names the operating problem.

A leverage loop is a designed feedback system for agentic work. It turns human intent into agent work, agent work into an artifact, the artifact into feedback, and feedback into a better system for the next pass.

Prompts, models, and tools all matter. The loop around the work matters more.

The agentic operator

The most interesting person in the agent era is the agentic operator.

By agentic operator, I mean someone who understands a domain well enough to know what good looks like, and is technical enough to use agents to build systems around that judgment.

Picture a PM using coding agents to prototype workflows, analyze customer behavior, and turn rough product hypotheses into working software. Or a data analyst using an agent across Slack, BigQuery, Jira, and Confluence to run root-cause analysis that used to take days of manual digging. Or a support, finance, operations, or growth person who knows exactly where the work gets stuck, but historically needed an engineering team to build anything useful around that knowledge.

Operators can gain technical agency without becoming software engineers.

The operator’s advantage is that agents make it possible to install reasoning and feedback loops closer to the work.

The operator can take a messy problem, aim an agent at it, give the agent tools, inspect what comes back, and improve the system after each run.

A root-cause loop across tools

Take a product manager investigating a sudden drop in conversion.

Historically, they might need to pull data from the data warehouse, search Slack for incident chatter, inspect Jira tickets, read Confluence docs for launch context, ask engineers for deploy history, and manually stitch together a story.

With agents, they can start to turn that investigation into a loop.

The PM gives the agent a loose aim: the metric that moved, the hypothesis to test, and the part of the system that seems suspicious. Then the agent explores. It inspects BigQuery and finds the relevant tables or fixtures. It runs small test queries before attempting the full analysis. It checks whether the hypothesis is pointed in the right direction. It searches Slack for related discussion, checks Jira for recent changes, and reads Confluence for product scope, launch notes, and experiment context.

The output is a first-pass analysis with evidence, assumptions, open questions, and recommended next checks.

The PM still owns the judgment, but they move out of the low-level handwork.

The job shifts. The analyst aims the investigation, decides what evidence matters, inspects the artifact, corrects the agent when it chases the wrong thread, and improves the loop so the next investigation starts from a better place.

At first, the operator may validate every step. Then the agent starts proposing a crisp plan and the operator validates the plan. Later, the operator gives the agent a hypothesis, the agent explores, comes back with a better approach, and asks for approval before executing.

For low-risk workflows, users can eventually self-serve through the agent without the original operator sitting in the loop at all.

This is how a single operator starts to make judgment travel farther: by teaching the loop where judgment matters, then moving to the smallest useful validation point.

From flow to loops

The Goal asked where the constraint was. The Phoenix Project asked where flow was breaking down. Leverage Loops asks where the loop is failing.

I keep coming back to that question when agentic work goes wrong. The obvious failure is usually a symptom: bad code, weak analysis, inconsistent output, or a demo that falls apart in real usage.

The first instinct is to blame the model. Sometimes the model is the constraint. More often, the deeper issue is the loop around the model.

The aim was fuzzy. The context was scattered. The tool access was wrong. The agent had too much scope. The artifact was hard to inspect. The feedback never made it back into the system. The next run inherited nothing from the last one.

When that happens, better models help less than people expect. A stronger agent inside a weak loop can move faster in the wrong direction, make more hidden decisions, and produce more convincing artifacts that still miss the aim.

More agent capacity makes the operating model more important.The Leverage Loops model

The framework has three parts:

1. AIM.

2. CONTROL.

3. LOOP.

Lets dive into each.

AIM: the initial bearing

AIM is the direction you are trying to point the system.

For small tasks, the aim may be obvious. Fix the bug. Summarize the document. Add the feature. Draft the email.

Meaningful work rarely starts that clean. You often begin with a hypothesis.

You think the customer problem is one thing, then the workflow reveals another. You think the product needs a feature, then usage shows the real constraint is trust. You think the agent should automate a process, then the failures reveal that the real opportunity is routing, escalation, or better human review.

Good operators can begin with imperfect aim. They need enough aim to begin, and a loop that helps them converge.

The distinction matters because agents can create the illusion of progress.

An agent can build the feature and weaken the architecture. It can answer the question and miss the decision. It can summarize the document and lose the insight. It can automate the workflow and create more cleanup work than it saves. It can satisfy the prompt while missing the aim.

AIM is the discipline of asking what you are actually trying to get the agentic system to do: what kind of progress should the system create?

CONTROL: keeping the system aimed

If AIM gives the system an initial bearing, CONTROL keeps it from drifting while the agent acts.

A large part of losing aim comes from weak control mechanisms. The agent gets too much scope, too little context, no stable source of truth, no way to check itself, and no clear boundary for what should remain unchanged.

So the work drifts.

The prototype works, but the abstractions are wrong. The analysis is detailed, but it answers the wrong question. The workflow runs, but nobody knows when to trust it. The agent makes local progress while the broader system loses coherence.

CONTROL is the set of mechanisms that keeps the system pointed in the right direction long enough to learn from the work.

In practice, control includes context, constraints, tools, permissions, tests, evals, review points, logs, artifacts, and source-of-truth documents.

For the analyst using agents across Slack, BigQuery, Jira, and Confluence, control might mean read-only access to production data, cited queries, and a clear separation between evidence and hypothesis. Control might also mean an incident-style artifact, explicit unknowns, and permission before changing dashboards, writing back to systems, or notifying the team.

Those controls make leverage usable.

They let the agent operate with enough autonomy to create value without letting it quietly drift away from the aim.

LOOP: the unit of agentic work

LOOP is how the system makes progress.

LOOP includes feedback after the work. It also describes the shape of the work itself.

At the smallest level, an agent is constantly moving through a loop: observe the environment, interpret the context, choose a step, use a tool, inspect the result, and decide what to do next.

The adaptive cycle makes agents different from static automation.

A script executes a predetermined path. An agent can react to what it finds.

The same loop creates both the upside and the risk.

An agent can explore a codebase, inspect logs, query data, read tickets, compare docs, test a hypothesis, and update its plan as new information comes in. A good operator takes advantage of that loop. The agent can adapt inside the work, so the operator can define the aim and review the evidence instead of predefining every step.

The loop works only when the conditions are right.

Missing context turns into guesses. Missing tools create dead ends. Weak data access forces the agent to reason from shadows. A messy environment sends the agent chasing the wrong thread. An unclear artifact makes progress hard to judge. No stopping condition lets the loop spiral.

Agents often fail in ambiguous environments because ambiguity requires a stronger loop. The agent needs enough context to orient, enough tools to act, enough structure to evaluate progress, and enough control mechanisms to keep from drifting.

For the analyst investigating a conversion drop, the loop is larger than “ask an agent for analysis.”

The loop is exploration, hypothesis, tool use, evidence, artifact, review, and improvement.

Inside that loop are smaller loops: query, inspect, revise; search, compare, narrow; hypothesize, test, update.

Outside it are larger loops: incident review, dashboard improvement, source-of-truth cleanup, better instructions, better tools, better future investigations.

The plural matters because the loops are nested.

The agent has loops. The task has a loop. The workflow has a loop. The operator has a loop. The system gets better when those loops reinforce each other.

A weak loop creates motion without convergence. The agent keeps acting while the work drifts from the aim. It reads more files without understanding the system. It runs more queries without finding the causal story. It writes more code without improving the product. It generates more analysis without clarifying the decision.

A strong loop creates convergence. Each step produces evidence. The artifact improves judgment. Failure sharpens context. Review improves the next run.

AIM gives the system an initial bearing.

CONTROL creates the conditions for the loop to operate safely.

LOOP is the cycle of work and feedback that moves the system closer to the right aim.

The loop executes the work and reveals what the work should become. That discovery is part of the work.

Shrinking the validation loop

A good leverage loop often keeps human judgment in the system, then gradually shrinks the validation loop.

At first, the human reviews every step because the agent still lacks enough context, tools, or trust. Then the human reviews plans. Later, the human reviews outputs. Eventually, the human reviews only exceptions.

For low-risk, well-understood workflows, the human can leave the loop almost entirely. Other workflows should keep human judgment close to the work.

Autonomy is one of the easiest traps in agentic work. People see the possibility of removing the human and assume removal is the objective.

Useful leverage depends on the right level of control.

Deterministic work should use deterministic software. Stable decisions should become rules. When the same path should run the same way every time, a traditional workflow may beat an agent.

Agents are most valuable where the work requires interpretation: exploring ambiguous context, synthesizing across tools, testing hypotheses, handling messy inputs, and escalating uncertainty.

That kind of work still needs validation. The useful question is where the validation should live, how expensive it needs to be, and how the loop can make it smaller over time.

Why this is different now

Feedback loops were always important. The lineage from The Goal to The Phoenix Project already says as much.

What changes with agents is the cost of installing them.

Previously, much of loop-building required humans to do the glue work: collect the evidence, inspect the logs, update the rules, rewrite the process, and carry context from one run to the next.

Now agents can help build and maintain parts of the loop themselves. A coding agent can create the data pipeline. An analysis agent can inspect the logs. A documentation agent can update the runbook. A review agent can compare outputs against prior failures. A workflow agent can try again with better context.

The operator becomes more important, and the role becomes more load-bearing.

The operator decides what matters. The operator decides where reasoning should live. The operator decides what controls are needed. The operator decides what evidence changes the aim. The operator decides when the system is ready for more autonomy.

The agentic era rewards the person who uses AI to make judgment travel farther.

The enemy is leverage without an operating model

AI creates leverage. The mistake is believing that leverage manages itself.

Drop agents into old workflows without changing the operating model and the pattern is predictable. Output increases while coherence drops. Automation expands while accountability weakens. Speed rises while context debt piles up. Autonomy grows while feedback gets thinner.

The pattern appears when a workflow gains leverage without loops. The agent can act while the system fails to learn. The agent can produce while the operator loses the ability to steer. The agent can move quickly while nobody knows whether the work is converging.

Leverage Loops is meant to diagnose that failure mode.

Move past the question of whether the agent was good enough. Ask where the loop failed: was the AIM clear enough to begin, did CONTROL keep the work pointed in the right direction, and did the LOOP capture feedback and improve the next run?

Those questions work at several levels.

For a coding-agent task, the model becomes the project brief, test plan, and pull request artifact. For a data investigation, it defines the agent’s tools, source access, analysis template, and review process. For an applied AI workflow, it sets routing, escalation, evals, logs, and human validation. For a personal operating system, it governs how context, memory, and project rules improve over time.

The model is simple: AIM, CONTROL, LOOP.

Direction, boundary conditions, converging work.

The operating model I keep coming back to

I expect Leverage Loops to keep changing as I use it.

I am building it in public through coding agents, applied AI workflows, personal operating systems, product work, data investigations, and the messy places where human judgment meets agentic execution.

The more I work, the more I keep seeing the same pattern.

Agents work well when an operator builds a better loop. The operator gives the system an aim, creates enough control for the agent to act without drifting, shapes the work into inspectable artifacts, and uses feedback to tighten the next run.

Over time, the loop gets smaller, faster, and more trustworthy.

I want to keep testing that operating model here.

The factory needed a way to see constraints. Software needed a way to see flow. Agentic work needs a way to see loops.

Leverage Loops gives that work a name.

A prompt can produce output. A workflow can produce repeatable output. A leverage loop improves the system that produces the output.

A leverage loop gives you a way to direct agentic leverage without drowning in side effects: hidden decisions, context rot, brittle automation, and impressive artifacts that miss the point.

The deeper work is installing loops that let agents reason inside the workflow while humans stay responsible for aim, control, and judgment.

The Goal taught us to manage constraints. The Phoenix Project taught us to manage flow. I want Leverage Loops to teach how to manage feedback systems around intelligent agents.

Aim the system. Control the work. Close the loop. Then use what you learn to build the next one.

If you consider yourself a “non-technical” person but a power user of AI tools, you’ve probably leaned on these systems and felt two things at once:

1. That there’s far more here than you’re getting

2. A nagging worry that if anyone can do this, doing it won’t get you ahead

Both of these feelings are valid.

Yes, the floor has clearly risen. You can prompt your way to something that works in an afternoon. You can build something in a single session which would have taken weeks or even months pre-AI.

At the same time, you see cracks around the edges of your creations. You hit a ceiling of complexity. What starts well invariably goes off the rails as your agent stops following instructions and you just can’t seem to get what you want. Your UIs look “nice” but clearly vibe-coded. Features “kinda work” but fall apart around edge cases.

You see posts online about people creating things far better than what you seem to be able to make. There’s a voice in your head that wonders:

That second question is the one that stings, and it treats “anyone can” and “anyone will” as the same thing.

Almost everyone can get something built. Most will stop there. And of the people who keep going, there is another split: getting a working artifact and converging on the thing you actually needed are different skills.

Most people settle for the plausible version and never cross that gap.

I lived in that gap for years, and you might know the shape of it.

I was a systems analyst, then a “technical” product manager. Maybe you’re the program manager that lives in SQL and Looker dashboards, or the consultant with a keen sense for when the data you’re getting from your data analyst isn’t quite correct.

Turning that intuition into real change often meant needing code.

Code is precise and unforgiving. It requires precise syntax.

There is no “pretty close.” It either will not compile, or your data simply will not do what you need it to do. I would invariably hand the build off to my technical partners and sit on my PM hands. I always needed a collaborator to clear the constraint the rest of the way.

That was the deal, and as much as I tried to fight it, it felt like it was permanent.

It felt like the intuition and insight might be mine, but the build would always someone else’s. The wall between seeing a fix and shipping it was one I would never get over alone.

Subscribe now

The curve didn’t flatten, it stretched

As AI models continued to advance and tools like Claude Code became viable, that wall began to fall rapidly throughout 2025.

The work that used to sit between a hard earned product insight and a built thing, the craft to learn, the plumbing to wire, all the doing-of-the-things-around-the-thing, is exactly what AI agents can absorb.

If you’ve ever been the person who could see where the work needed to go but had to hand the building to someone else, that handoff is rapidly dissolving if you have the appetite to dive deep. You can take a hunch about where the problem sits and chase it straight into something real, steering while the agent does the building.

That moves the gate. It used to be whether you could build the thing at all.

You have probably seen people on LinkedIn or X proclaim that now it is all about “taste.” Personally, I HATE how that word has become shorthand for good work, because it makes the skill sound mystical when the practical version is much more useful.

The better word is convergence.

Convergence is knowing how to find what is worth building, choose the shape it should take, and steer your agents until the result matches the need.

This is a learnable skill and a process.

That is where the usual story breaks. People hear “the agent does the execution” and assume execution has become free.

The syntax has: typing code, wiring plumbing, remembering exact configurations. But getting a real thing built under real constraints is still execution. It just moved up a level.

The people who call it solved are usually stopping at the first plausible artifact. They are not doing the harder work of finding the real target, choosing the right container, and steering the build until it lands.

That is why I do not see what is happening as a “great leveling,” where the floor gone, anyone builds, and talent stops mattering.

Not until super-intelligence pulls humans out of the loop entirely. Until then, the human loop still matters a lot. It matters now more than ever.

Picture a bell curve. The middle is getting taller and narrower as more people produce competent, plausible output from the same models. But the tails are stretching too, because the people who can steer the agent toward the right target can now build far more sophisticated, feature-rich things much faster.

Everyone gets more leverage. That part is obvious.

The point that matters now is whether you can turn that leverage turns into the things you need.

The three ways agents break

An agent can build something plausible from almost any instruction. That is the promise and the trap. Working output can hide three different problems: the target is wrong, the shape is wrong, or the execution drifts before the thing is actually done.

The first way it breaks is that you do not really know what you want yet.

This isn’t because you are careless, but because on anything that matters the right answer usually sharpens through contact with various options and feedback from yourself, your collaborators, or your users. You ask for the obvious version, the agent builds it faithfully, and you spend your leverage sprinting at the wrong target.

The first articulation is rarely the right one. The agent commits to it anyway, building your mistake to spec. On a front end UI, a document, or a slide deck you can at least see the mistake, but when it comes to backend workflows, data, your financial model, those flawed assumptions can linger and cause problems for you later.

The second way is more practical: you may know the outcome you want, but you choose the wrong shape for the solution.

Should this be a script, a tool for your agent, an app, an agent with helper tools, or an agent operating over Markdown files with its native harness? Should the state live in a database, JSON, a spreadsheet, or plain text?

Those choices can look like implementation details until they ultimately decide what the system can become and how it actually feels to use.

The third way shows up once the target and shape are mostly right.

Getting the agent to actually deliver the thing is its own skill. Anyone who has pushed past a simple task knows the feeling: you can see the thing, you can even describe it, and the agent keeps handing back something adjacent.

Maybe it subtly cheated, skipped steps, made a clear mistake as the work gets bigger.

This is why “can everyone do this” misses. Prompting is only the first step of agentic leverage.

The real skill is convergence: finding the target, choosing the form, and steering the build until the output matches the work.

The shape matters

The “form” question is where a lot of agent work fails.

A person asks for “a thing that tracks this workflow,” and the agent can produce a spreadsheet, a Notion database, a CLI script, a web app, a repo full of Markdown, or a small agent loop.

Each answer can be defensible, but only some of them fit the actual work. It is highly contextual to the specific problem you have.

This is the architecture layer operators now need to understand at a practical level. You do not need to become a full-time engineer, but you do need a feel for the tradeoffs. If you’re a product manager, you’ve already lived this.

The practical questions are basic, but make all the difference:

• Deterministic workflow or agent skill package?

• Structured database or markdown files?

• Custom app interface or general agent chat?

• Agent autonomy or human review?

• Dedicated helper tools or let the agent use its basic edit tools?

The agent can help you reason through those choices, but it will not feel the cost of the wrong container the way you will. It has no distaste for tedious workflows, it will work tirelessly for you.

When you come back and tell it it chose wrong, it will say “you’re absolutely right!” and pivot as quickly as it sold you the first approach.

That is why stronger models do not erase the skill. Yes, it does make things more forgiving; today’s models can undo prior mistakes with an agility that earlier models simply could not.

Still, when the model can build faster and with more complexity, the wrong form becomes a more sophisticated wrong thing.

When you choose the form well, the same capability lets you move much further and faster into the thing you actually need.

Scoping by subtraction

I hit this first failure mode rebuilding my own website (brandongalang.com).

I did not want it to look “bad.”

I wanted it to look well thought through and something that I could call my own. The way I got there felt easy and simple, but it was a workflow I had discovered through months and months of trial and error. The workflow that got me through is the one I would hand to anyone starting out.

Stop trying to describe what you want and start generating toward it. Lean on the agent to manufacture variance, then use your judgment as a subtractive filter, finding what you want by cutting what you do not.

You’ve probably seen posts describing how agents work better with highly detailed plans and how Claude Code or the newest model “one-shot” an impressive landing page. DO NOT buy into this idea of the “one-shot” workflow.

Don’t concern yourself with knowing up front, know upfront that you will build your way into it.

This is my preferred way of operating because generation is cheap now: you can spin up more candidates than you could ever make by hand, then chip away until what is left is the thing.

I have started to call this “generative scoping.”

Here is how it ran for me. I could not describe what I wanted from my own site, so I did not try.

I pointed the agent at sites from creators I admired: Dan Koe, Justin Welsh, and Mark Manson. I told it to study how they were laid out and adapt the patterns to mine.

Instead of a spec, I steered Codex towards the actual implementations. I told it to not only inspect the code, but also inspect the screenshots so it could see both the code and the explicit visual presentation of the websites.

It worked for awhile and generated a first draft that looked strikingly similar to Justin Welsh’s page. Then began the iterative process of adapting what it gave me.

“Remove the reviews, I’m not a New York Times best selling writer!”

“I prefer Dan Koe’s About Me section, pull that in instead.”

“Let’s try Light Mode, black and white feels a bit too copycat.”

“Here are images from Every, I really like their brand style. I like X, Y, and Z about this. Generate variants that lean into those elements but can make this uniquely mine.”

By the end of the afternoon, I had something that felt like mine.

This workflow works precisely when you lack the words for the target but have enough reps to know a wrong note the instant you see it.

Sometimes you do the cutting yourself; sometimes you hand the agent the criteria and let it prune inside its own loop.

And once a direction finally emerged, I locked it in: more reference images, a brand guide the agent could keep reinforcing across every future asset, so the convergence I had paid for did not slide back toward the average.

Decisions that make decisions

Now the third failure:

Converging on a direction does not ship the thing; decisions do. And with an agent, the decisions that matter most are the ones that shape the decisions it makes later, without you.

I call this focusing on “decisions that make decisions.”

Many things fall into category. Here are some examples:

• Your CLAUDE/AGENTS markdown file

• Your agent Skills

• Your Codex/Claude Code /goal prompt

• Your acceptance criteria

• Your plan

• Your process around sub-agent validation and review

Directly prompting an agent is only one way to steer it. Once it embarks on its run, these other elements you architect around it begin to matter more and more.

Get those right and your intent carries through a thousand small choices you never see. Get them wrong and the agent can send itself over a cliff the moment you look away from your Terminal.

Here are two examples I used with my website example from earlier.

I use a front-end skill set called Impeccable (impeccable . style), modules for typography, layout, alignment, the granular craft of applying design principles to the page. As I deviated from reference websites, my coding agent could reference these to drive my generative scoping process. The skills filled in for the design language fluency I lacked.

My decisions for how it would use these skills provided another set of guardrails to steer its execution.

I told it to run the skills sequentially rather than in parallel, so each pass builds on the refinements of the one before it instead of three skills competing for attention.

I delegated a sequence of skills around tasks that required little human judgment. Issues it found around typography consistency, spacing, alignment, responsiveness across mobile/desktop: these I allowed it to execute freely. Where it required a human touch and an opinion, I asked it to identify issues, brainstorm approaches, prioritize them, and present them to me.

Underneath all of it ,the agent had real visibility into the repo and the deploy through Cloudflare, so I could point and let it connect the technical, tedious dots that were never where my value lived.

You have to fight to escape the middle

Execution friction used to hide the difference between people.

When everyone struggled to make the thing work at all, the struggle passed for rigor. It was harder to see who lacked a real opinion, because few got far enough to reveal one.

Take a lot of that friction away and there’s nowhere left to hide.

The execution that still matters is problem-solving execution: finding the right target, choosing the right container, and driving the work to closure through ambiguity, edge cases, and tradeoffs. The agent will happily produce plausible midpoints forever. Convergence is the skill of forcing the output to become the needed thing.

If you remember one thing, make it this:

You’re going to get something that looks good long before you get something that’s right. When that happens, don’t assume you’ve hit your ceiling.

Assume you’ve reached the midpoint, then keep steering.

A year ago, most AI conversations I had at reunion were extreme bullishness on my side and either skepticism or mild curiosity from my colleagues.

Someone would ask what I was using AI for. I would show them a Deep Research run in ChatGPT. They would scroll through the sources, the follow-up searches, the synthesized answer, and usually have the same reaction:

This year, I kept walking into conversations that had already started without me.

People were talking about coding agents like Claude Code or Codex. Some were trying them. A few had already built things.

One former banker had built a simple app prototype and already had real buyer interest. Someone had started their own digital marketing agency was using AI to analyze sentiment data at a scale that would have been painful and/or infeasible to do manually. A good friend of mine who works in GTM strategy used AI to rapidly iterate on slides and narrative. An animator/designer had been pushing Claude Code into a complex, interactive front-end project.

It was an interesting weekend seeing how much the conversation had developed. Despite my colleagues being more bullish than I’d ever seen them, I also became even more convinced that the hard part is going to be less obvious than people expect.

The easy wins have a shape

A lot of AI work and what separates low and high skill AI users now comes down to task and environment design.

Task design is the starting point.

As you get better, the next lever is the environment around the task: what context the agent sees, what state it can trust, how quickly you can inspect the output, and how easy it is to recover from a bad step. That is how you start taking on harder kinds of work without just hoping the model gets smarter.

The banker prototype is a good example. From the outside, it sounds unbelievable: a non-technical person building a software product. But the actual task was very friendly to AI.

It was a simple CRUD-style prototype. No multi-tenancy. No production deployment. No permissions model. No compliance surface. No operational hardening.

That is not a criticism. That is exactly why it worked. He wasn’t trying to vibe code the production system; he was finding an engineer to help with that. His prototype just needed to convey the vision.

The job was to make an idea tangible enough that someone could react to it. The prototype did not need to be perfect or even function properly with a genuine backend. It simply needed to exist and look the part. A buyer could click around and say, yes, this is useful, or no, this misses the point.

The artifact created feedback.

The marketing example had a similar shape. He was using AI to analyze social sentiment and campaign feedback. That is a natural fit for an agentic workflow. The model can inspect, cluster, summarize, and surface patterns. Just like coding agents can naturally crawl a sprawling codebase, it can easily sift through social media posts. You still need judgment, but the task tolerates exploration. It does not require a clean production pipeline before the work has value.

A tight loop beats raw confidence

My GTM strategy friend’s workflow was more mundane, and probably more instructive.

She was using AI the way she might delegate to a junior analyst back in her consulting days. Make a version of this slide. Try a different phrasing. Duplicate the slide first. Keep the original. Compare the options. Reject the bad ones. Read my comments on slide X and make the adjustments.

The loop was tight.

The output was visible. The original was preserved. The cost of a bad suggestion was low. She never had to trust the agent across a long chain of invisible decisions. She approved literally everything. No YOLO mode here.

That caution helped her. She was less bullish than some of the people having worse experiences, so she kept the agent on a short leash. I also think she was leaving upside on the table. The same loop could support more ambitious work if she pushed it further.

The key was that she had a loop.

When the setup fights the work

The animator had almost the opposite problem.

He was much more technical and had a non-SWE engineering background. He had genuine taste. He had a real project. And he was working in a domain that should benefit from coding agents; he was literally coding.

But the task had a nasty shape.

He was layering multiple interactive components and motion states into a screen. For that kind of work, the static structure has to be designed around the intended movement. If a component needs to expand, transition, rearrange, or respond to input, the code structure has to support that range of motion early.

You can get pretty far with incremental edits on a static screen. Motion changes the constraints.

That was where the workflow started to spiral.

He added more comments to the files. He wrote down more instructions. He tried preserving more state by telling Claude to save meticulous notes. He fed annotated screenshots back to Claude.

All of those moves make sense in isolation. If the model is losing the plot, add context. If the visual output is wrong, show it images. If the desired behavior is subtle, explain it more precisely.

But the system was already pointed at the wrong problem.

The comments were probably preserving stale reasoning inside the codebase. Some of that reasoning may have been wrong. Now Claude was reading old assumptions as part of the current source of truth.

The files got heavier. The context window got noisier. The exact intent still had to survive compaction. The screenshots helped in spirit, but Claude likely did not have enough visual fidelity to map a subtle animation issue back to the exact code that needed to change.

The screen needed a structural refactor to support the motion. The agent kept getting asked for tweaks.

More context is not always the fix

This is the failure mode I think more people are going to run into.

AI makes the first version easier. It also makes the wrong path feel productive for longer.

When a task is shaped well, the tool feels like magic.

When the task is shaped poorly, people often respond by prompting harder. More details. More context. More rules. More screenshots. More examples. Correct that this way. Redo that by doing this instead.

Sometimes that works. Oftentimes, you end up stacking bandaid after bandaid until the underlying files are jumbled beyond repair.

Often, the setup is the problem.

A good AI workflow has to match the work. A prototype needs enough structure to create feedback. Analysis needs source material the agent can inspect. Slides need visible reversibility. Animation needs a way to preserve intent, observe behavior over time, and refactor when the structure is wrong.

The next practical skill

This is why I am so bullish on agents and still careful about how I use them.

The tools are clearly good enough for normal people to do useful work. I’ve known that for months and my beliefs here were validated all weekend. People who would never call themselves builders were making software-shaped things, analysis workflows, and presentation systems.

The ceiling comes from the setup.

The agent needs the right environment. It needs state you can trust. It needs outputs that show whether they worked. It needs a feedback loop tight enough for the precision of the task.

A simple prompt can work beautifully when the agent is grounded in the project. A detailed prompt can still fail if the environment is fighting the work.

That is the next practical AI skill for knowledge workers to wrap their heads around: task design.

• When can the agent explore?

• When does it need a plan?

• When should you preserve the original?

• When should you stop tweaking and change the structure?

The people who learn to answer those questions are going to get much more out of these tools and have much faster learning curves. Everyone else may still get something impressive on the screen.

They just may not know whether they are building leverage or digging the hole deeper.

-Brandon

Read more

"One click. Full production app. Just describe what you want and watch the magic happen."

If you've tried these tools, you know it's bullshit. AI can get you close by operating at a higher altitude where syntax becomes irrelevant. But you still need to know what you're asking for—or how to get AI to tel…

Read more

I've watched this play out so many times. Two teams at different companies launched similar AI pilots within weeks of each other. Both had executive backing, solid technical talent, and access to the same cutting-edge m…

Read more

Not the gap between their skills and the role. The gap between Monday's coffee chat and Friday's thank-you note. The gap between reading a job post and tailoring the resume. The gap between the interview stumble and the next chance to practice.

These gaps compound. A week becomes a month. Momentum dies.…

Read more

The YC founder smiled. "Someone shared it in our Slack. We're building something similar. Your approach is very much aligned with what we've been thinking and building towards."

I write for a small network, mostly documenting my own experiments. But "How I Built an AI-First Knowledge System That Actually Works" seemed to resona…

Read more

Every morning, I'd open my laptop to a constellation of disconnected tools: Notion docs scattered like digital tumbleweeds, GitHub repositories hiding critical context, Asana tasks multiplying faster than I could complete them, and emails breeding in my inbox like rabbits. I'd spend the first hour of my "productive" da…

Read more

It's brutal.

They wait weeks, months, sometimes YEARS, while I juggle scal…

Read more

This is the story of how I built this:

Read more

"Should I use LangChain? Maybe its graph-based evolution LangGraph? But what about CrewAI, a role-based multi-agent orchestration framework?

Wait, PydanticAI seems even better though, and comes from a highly regarded Pythonic team.

Then agai…

Read more

You capture everything. Index religiously. Tag meticulously. Then when you need that brilliant insight from three months ago?

You stare at a search bar, hoping keywords will surface gold from your digital haystack.

After multiple failed attempts with di…

Read more

"Got the new Jira MCP server working - this thing is incredible! It's summarizing my tickets exactly how I want. Will report back once I test it more."

A few days later, I finally got around to setting it up myself. I was super excited after his initial report and quickly got it running.…

Read more

Earlier this week, I spoke to a friend who was shelving his Slack bot project after realizing the "repetitive" questions weren't actually repetitive, they just looked that way.

This revealed a pattern I've seen across dozens of failed automation a…

Read more