In The Signal Under the Noise, I wrote about AI noise—the gap between what people produce and what they understand. That was about individuals. This is about the process around them. Because something shifted in how we work, and it took us a while to name it.
The craft we learned
The craft of working with AI used to be about managing the AI. Prompt engineering. Token windows. Breaking tasks into pieces the model could handle. The bottleneck was the AI—its context was limited, its reasoning fragile, and your job was to work around those limits.
That's not where we are anymore.
What shifted
The models got better. Context windows grew. Reasoning improved. Tools like Dap give agents access to the full codebase, the architecture, the history. The AI doesn't forget what it was doing. It doesn't lose track of the plan.
We do.
I noticed this while working on Jira integration for Dap. Weeks of work, spread across multiple sessions, interleaved with other tasks. The AI handled the complexity well. It could pick up where it left off, follow the plan, implement edge cases I'd specified upfront.
The problem was me. After a few days working on other things—polishing, smaller features, reviews—I'd come back to the Jira work and feel the weight of re-entry. Not the code. The code was there. The decisions. Which approach had I chosen? What order were the remaining pieces supposed to go in? Were those changes still the right changes given what had moved in the meantime?
The AI had the context. I'd lost mine.
This is the shift: there is no AI context problem anymore. There's a human context problem. I call it context drift—the slow erosion of your own decision state as you move between workstreams. The AI remembers your plan perfectly. You remember a version of it, colored by everything else you've done since.
Teams are still optimizing for AI limitations that are shrinking fast—better prompts, smaller tasks, more guardrails. Meanwhile, the actual constraint is the person driving. Can they hold the plan across sessions? Can they switch between workstreams without losing the thread? Can they come back to a complex feature after three days and trust their own previous decisions?
Where the leverage moved
What matters now is what happens before the AI starts working.
Planning is the highest-leverage activity. The better you define the work upfront—scope, edge cases, order of operations—the longer the AI can run without you. A well-planned task lets you hand off and switch to something else. A vague one pulls you back every ten minutes.
Edge cases are the real deliverable. The AI will implement the happy path without much help. Your job is to find the border cases before coding starts. Every edge case you identify upfront is an interruption you won't face later. Every one you miss is a context switch that breaks your flow.
AI utilization time is the metric. The goal isn't "how fast can the AI code." It's "how long can the AI work before it needs me." That's a function of planning quality, not AI capability. If the AI keeps stopping to ask questions, the plan wasn't good enough.
The developer's job shifted. You're not writing code anymore. You're writing the spec that lets the AI write the code. Planning is the new programming.
The merge path problem
This pattern shows up everywhere, but the merge path makes it concrete.
Right now, a human sits in the review-and-merge loop for every PR. That made sense when AI output was unreliable—you needed a person to catch what the machine missed. But the quality gates have changed. Code review tools like CodeRabbit catch structural issues. Unit tests, end-to-end tests, and linters verify behavior. The automated checks are doing real work—not rubber-stamping.
So we're asking ourselves: if every quality gate passes, what is the human in the merge path actually adding? Is it judgment—or is it latency?
We don't have a clean answer yet. There's a version of this where the human review still matters—for architectural coherence, for intent, for the things automated tools can't evaluate. And there's a version where the human is just the slowest step in a pipeline that's already validated the work. We're thinking about auto-merge—letting PRs that pass every check flow through without waiting for a person. The details deserve their own entry. What matters here is the question it surfaces.
Because once you start pulling at this thread, you find it everywhere. The merge path is one bottleneck. CI pipelines designed for a human pace are another—queues backing up because the infrastructure assumes you're not shipping this fast. And behind all of it, more often than we expected, is the human. The person who needs to define the next task, make the next decision, provide the next plan.
The pattern keeps repeating. You look for the bottleneck and find the human underneath.
Staying ahead of the machine
This changes what "being good at AI-assisted development" means. It's not about prompt engineering anymore. It's about staying ahead.
When the AI is working on task A, you should be planning task B. When task A's PR is in CI, you should be reviewing the output of task C. The AI doesn't need you to watch it work. It needs you to stay ahead of it.
I learned this the hard way during the Jira integration. I had three things running: the Jira feature, a round of UI polish, and a bug in the event system. I'd finish planning one, hand it to the AI, switch to another. The AI was never idle. I was never idle. It felt productive.
Then I came back to the Jira work after two days on the other streams. I spent forty minutes re-reading my own previous session notes, trying to reconstruct why I'd chosen a particular approach for webhook handling. The AI was ready to go. I wasn't. That forty minutes wasn't the AI's limitation. It was mine—context drift in action.
The new skill gap isn't "can you use AI tools." It's "can you keep up with them."
The supervisor I keep wanting
After the forty-minute ramp-up on the Jira work, I kept thinking about what would have helped. Not a better AI. A better bridge back to my own previous thinking.
I've started calling it a supervisor—but not for the AI. For the human.
Picture this: you're running three workstreams. The Jira integration, a UI polish pass, and a bug fix in the event system. You switch from Jira to the UI work. Two days later, you come back to Jira.
Something knows where you left off. Not just the code state—the decision state. It knows you chose approach B over approach A because of a constraint you identified last Tuesday. It knows the next three steps in your plan and which ones are still valid. It knows that while you were away, a dependency changed that affects step five.
It doesn't make decisions for you. It reconstructs your context so you can make decisions without the forty-minute ramp-up. It's the difference between opening a blank page and opening your own notes—except the notes are always current and always complete.
I'm not sure yet whether this is a tool, a practice, or an AI agent with a different mandate. Maybe it's just disciplined note-taking that I haven't been disciplined enough to do. But the need is real—human continuity, fighting context drift at the source. The ability to pick up exactly where you left off, across any number of parallel workstreams, without the cognitive tax of reconstruction.
What this means
If the bottleneck is human, the implications ripple outward.
Team processes designed around AI limitations—mandatory human review of every PR, breaking work into tiny AI-sized chunks, extensive prompt libraries—are solving yesterday's problem. The processes that matter now are the ones that help humans stay coherent: clear planning rituals, decision logs, workstream state that's visible and current.
We're seeing this in our own team. The constraint isn't "can the AI do it." The constraint is "can we feed it fast enough, with enough clarity, and maintain our own understanding while it runs."
@icesarani wrote about Building the Plane While Flying It—how the team had to rediscover project fundamentals when AI accelerated everything. This is the individual version of that same pressure. The team needed better coordination. The individual needs better continuity.
Open questions
We're naming this, not claiming to have solved it:
- How do you measure context drift? I can feel when it's high. I don't have metrics for it yet.
- Is there a natural limit to how many workstreams one person can manage, regardless of tooling?
- Could a supervisor-like tool actually solve context drift, or would it just move the problem somewhere else?
The sharp edge
We invested heavily in learning to work around AI limitations. The models improved faster than our habits did.
Now the AI waits for us. It finishes a task and waits for the next plan. It merges code and waits for the next specification. It's ready. We're the ones catching up.
The bottleneck flipped. And the uncomfortable part isn't that the AI got faster. It's that we're the constraint we never learned to optimize.