AI tools and how we work

AI made starting and producing work nearly free, but didn’t make understanding, verifying, or coordinating any cheaper. People optimize for what feels fast, so they over-invest in the cheap part and under-invest in the expensive ones.

Three problems

Less human communication. The AI is always available, never impatient, and never makes you feel slow, so asking it takes less effort than asking a colleague. Quick questions to colleagues used to spread context and keep people aligned. Now that context stays in private chat sessions. The team loses a shared view of how the system works and where it’s heading, and people break things other parts of the system rely on, often without knowing those dependencies exist. People end up with more code and less collective knowledge.

Parallel threads and shallow thinking. Running 3–5 agent sessions feels productive because something is always progressing. But you become a dispatcher and reviewer, constantly reloading context, and review quality drops as you approve diffs you’ve half-read. Work that spans several interacting components doesn’t parallelize. Parallelism works for well-specified, low-risk tasks and works poorly for anything requiring judgment.

Ship and move on. This is the most dangerous of the three, especially in infrastructure. When producing a fix takes 10 minutes, spending hours confirming the intended effect and looking for the unintended ones feels disproportionate, so people skip it. But verification costs as much as ever, and side effects (node churn, retry storms, CDC/replication lag, connection pool exhaustion) rarely show up right away. They build over time or appear only under different load.

Mitigations that seem to work

• Adjust what “done” means. A change is done when you’ve confirmed in production that it had the intended effect and no side effects. Before you release, note how you’ll check both. An agent can help: put a verification step in its instructions, and it will review production metrics and logs after release. I have agents re-check for regressions a few hours, sometimes even days, later.
• Limit work in progress per person. One well-known estimate puts the cost of each added task at about 20% of your time lost to context switching; beyond three, more than half goes to switching. Limit yourself to one deep task plus one or two mechanical agent tasks. I sort my agent sessions into two lists, WIP and HOLD, and keep at most three in WIP. I work only on WIP. I don’t start anything new or pull anything back from HOLD until a WIP slot frees up, either because a task is done or because I move one to HOLD.
• Decide with the team before you build. If you write code first, even with AI, you grow attached to it, and it frames the discussion around your solution instead of the problem. Ask the AI for options and a recommendation, work out who would notice if the change went wrong, and discuss the options with them and your team. Only then implement what you agree on. Waiting for teammates is fine: a short delay costs less than building the wrong thing. The team stays aligned, and everyone understands the change.
• Make AI-assisted work visible. A quick fix can break parts of the system you never touched. Before you ship, post a short note in the team channel on what you plan to change and why, and give people time to respond. Write the note yourself, not with AI: teammates skim AI-written summaries, but they read a few lines in your own words. Now and then, pair with a teammate on an AI session.

Measure outcomes

The metrics that matter now show whether changes work: change failure rate, rollbacks, rework, and the time it takes to detect a regression.

The bottleneck has moved from writing changes to judging them. Anyone can produce a change in minutes now. Knowing whether it’s the right change is the scarce skill, and the one that matters most. A fast fix is worth little if you don’t understand what you’re fixing and how. If we reward speed, we will get more changes and fewer people who know why they broke.