Years ago, our heaviest users were complaining that one of the screens they spent the most time in was getting slow. The pattern was clear in support: not one ticket but a cluster of them, the same complaint in different words. The screen worked fine for typical use but it didn't scale well. The customers who pushed it the hardest, the ones generating a lot of data, were the ones running into a wall. Which was, in a way, good news. The people complaining were the people getting the most out of the product. We just had to make sure the thing held up under their load. We talked to some of them. We pulled some usage data to see how widespread it was. We had a brief by the end of the second week: the screen needed to hold up no matter how much data a customer threw at it.
Then we sat down to decide whether to build the new version ourselves or use a library.
We did the comparison properly. We listed what we needed. We looked at what was already out there. By the third library demo we were two hours past the meeting, talking about everything else we could now do with it.
We picked the library. The next few months were heads-down work. A lot of building, a lot of iterating, a lot of long days. We shipped.
What we shipped was, honestly, a thing of beauty. We'd been seduced by what the library could give users. Better interactions. Smoother flows. New capability we'd never had before. While we were at it, we knocked off a stack of other features customers had been asking for. Each feature had a customer name attached to it. Each feature answered a real request. Each feature was something we could point at and say the customer is better off now. The kind of work you're proud to put your name on.
It was only afterwards that I realised something I'd taken for granted the whole time. The original problem was being taken care of. The library was the kind of solution that was supposed to handle it. That part of the work wasn't visible because it didn't need to be visible. It was solved by the choice we'd made early on. Or so I'd assumed. Nobody had gone back to check. I hadn't gone back to check. The library was doing what it did. Whether what it did was the thing we needed it to do was a separate question, and that question hadn't been asked since we'd picked it.
Not quite scope creep
The instinct is to call this scope creep. It isn't quite. Scope creep is undisciplined: a team saying yes to whatever shows up. We weren't undisciplined. Every feature we shipped had a customer behind it. Every feature answered a real request. Every feature was a real improvement. We were saying yes to the right things, just not to the thing that mattered most.
The original support tickets were still there. Nobody had deleted them. We could have searched for them in five minutes. We didn't. The library was in front of us every day. The other tickets we were working through were in front of us every day. The original brief was not. Attention follows what's loudest in the room, and over months, the loudest thing changed.
The brief stopped travelling with the work. Not because anyone decided to abandon it. Because nothing in the process was carrying it forward.
That gap, between what work is started for and what work eventually becomes, is the alignment tax. The version I want to point at lives inside a single product team, every week, mostly invisible, paid in features that ship and don't get checked against the problem that started them.
What it costs
The story doesn't need a villain. Nobody on our team forgot the original tickets. They just didn't have a reason to look at them again. The work had moved on. This is the same shape as the previous two posts on this site: context exists, context doesn't travel, the further the work gets from where it was triggered, the less the trigger remains in view.
The first cost is that the brief gets left behind. The brief we'd written by the end of the second week stopped being something anyone was reading by the end of the third month. The support tickets behind it stopped being read even sooner. The trigger had done its job. It had launched the project. After that, nothing in the process was carrying it forward. Work drifts towards whatever's loudest in the present. In our case, that was the library and what it could do. In another team's case, it might be a stakeholder request, a competitor feature, a bug somebody escalated on Friday afternoon. Whatever's freshest wins.
The second cost is the most expensive, and it's the one nobody puts on a dashboard. The work ships without anyone going back to check it against the original problem. That doesn't mean the original problem is necessarily unsolved. It might be solved. It might not. The team genuinely doesn't know, because checking against the original brief stopped being part of the process somewhere along the way. The shipped thing looks fine. It works. Whether it fixes what was broken is a separate question that nobody's holding open. You sometimes find out later, when a customer raises the same ticket again, or when somebody on the team notices that the metric you used to talk about hasn't moved.
John Cutler has been calling this for years. In his 12 Signs You're Working in a Feature Factory, two of the signs are no measurement of impact and success theatre around shipping. The factory ships. The factory doesn't check.
The third cost is a measurement cost. When we shipped, we measured what the new feature could do. Adoption. Engagement with the new surface. Time spent. We weren't measuring what we'd set out to measure, because by then that wasn't the question being asked. The success criterion had drifted alongside the work. Marty Cagan has a piece on this called Outcomes Are Hard. His point: most teams default to measuring what's easy to measure, not what would tell them whether they'd solved the problem. The fix is to define the measure of success at the same time as the problem, and to instrument the product so the team can actually see whether the outcome's been hit. We didn't do either. We measured what the dashboard happened to surface. You can ship something, declare it a success against those numbers, and still not know whether you've solved the problem you started with. The dashboard goes green. The customer who raised the ticket might still be waiting.
The fourth cost is one I only saw years later. The reason for the work disappears. If you'd asked me, two years after shipping, why we built the feature the way we did, I'd have said "because of the library." That answer is true and useless. The real answer was the customer pain that started everything off. That answer was already gone. The next person who picks up the area inherits a design shaped by a decision they can't access. They make changes that make sense given what they can see, and the original problem moves further from being solvable, not closer.
Addy Osmani has a related piece on what he calls comprehension debt: code that ships and that no human on the team genuinely understands. That's the same shape, one layer down. The alignment tax is what comprehension debt looks like before the code gets written. The decisions that produced the code are the things that drift first; the code itself is just the receipt.
At human speed and at agent speed
I made that mistake at human speed, with a human team, over months. The library was the loudest thing in the room. The original tickets were not. The brief didn't travel.
Now run the same setup with an agent.
You describe the problem in a prompt. The agent proposes a solution, builds it, and ships it. There's no library shopping, no team meeting, no months of heads-down work, no Friday demo. The whole loop runs in an afternoon.
The agent doesn't know the original tickets exist. It only has what's in the prompt. Whatever isn't in the prompt is gone. If the prompt is broader than the original problem ("make this part of the product better" rather than the specific frustration customers were raising), the agent will make it better in some direction, ship it, and you'll be left with the same gap we had, in a fraction of the time. The four costs don't go away. They get paid faster, with fewer chances to catch the drift, and against a brief that's even narrower than ours was.
An agent is only as good as the context it has. Whatever the team was already failing to carry, the agent inherits.
And it isn't one agent working alone. Some of the team are working alongside their own agents. Others are picking up tickets unattended and shipping by the afternoon. The same gap, amplified, replayed in parallel, across the queue.
I wrote a couple of weeks ago about agents starting cold every session, with no accumulated sense of why a thing matters. This is what that costs you in practice. Not "agents make worse decisions in the abstract". Agents will ship faster than your team can check whether the thing was the right thing to ship.
A question
The alignment tax is something every team is paying. Most teams don't see it on the invoice. It shows up later, in features that nobody went back to check, in dashboards that go green while the original problem stays open, in handoffs where the brief got rewritten silently along the way.
So the question I'd ask, if you've read this far, is this. When was the last time your team went back and checked whether the thing you shipped actually solved the problem that triggered the work? Not "did the new feature get used". Not "did the metrics move". Did the original problem, the one in the original ticket, the one in the original conversation, get fixed?
If the answer is "we don't really do that", then how would you know?