The invoice-reconciliation agent's code is in good shape. Extraction held up, the UI survived contact with real production data, and none of what's stalled right now has anything to do with any of that. I'm waiting on the same SAP/Ariba dependency I've written about before — this time because the one person who actually knows this system keeps getting pulled onto other priorities, and until he's free, nothing on this thread moves. More engineering effort, better AI tooling, a faster agent — none of it moves this forward even slightly. The thing I'm blocked on was never an engineering problem, and no amount of alleviating my engineering capacity was ever going to touch it.
I've been saying for a while that leaders need to ask how AI can alleviate their engineering capability bottleneck. I still think that's a fair question. But sitting here, actually blocked, by exactly nothing that engineering effort can fix, made me want to check whether it's the right question — and there's a sharper one underneath it that a piece making the rounds this week states better than I would have: engineering was probably never the real bottleneck to begin with.
The argument, and it's a good one: engineering throughput looks like the constraint because it's the part you can measure — headcount, velocity, a burndown chart — and hiring against it feels like doing something. It's also the answer that protects leadership from a harder question, because "we need more engineers" doesn't require anyone to admit the strategy is unclear or the decisions are slow. The actual constraints — strategy, prioritization, who's allowed to decide what, how many teams a single change has to route through — don't show up on a velocity chart at all. They just sit there, doing their damage quietly, while everyone stares at the engineering number because it's the one in front of them.
The line that stuck with me: the cost of being wrong increases as execution becomes easier. Cheap, fast code doesn't fix a bad decision. It just lets you ship the bad decision faster and find out you were wrong sooner, at higher volume.
CircleCI's 2026 State of Software Delivery report — seventh year running, 28 million CI workflows — found engineering throughput up 59% year over year across the board. Good news, on its face. Except the gain is wildly uneven: the top 5% of teams nearly doubled their output, the median team improved by 4%, and the bottom quartile saw no measurable improvement at all. Same access to AI, same faster code generation, and most teams still didn't ship meaningfully faster. If engineering capacity were actually the constraint, giving every team the same capability boost should have moved every team by roughly the same amount. It didn't, which means for most of those teams, engineering was never what was holding them back in the first place.
Not "how can I use AI to alleviate my engineering bottleneck" — that's still a fine question for the teams where engineering genuinely is the constraint, and some teams are exactly that. The sharper one, the one that's easy to skip past when you're already busy: is engineering actually my bottleneck, or is it just the part I can see and act on, while the real one — a decision nobody's making, a dependency on a team that isn't in the room, a priority nobody's willing to say out loud — sits somewhere I haven't been looking?
I know which one it is for me this week. It's not the code. It's one person's attention, split across other people's priorities that outrank mine, and the honest move isn't to write faster code while I wait. It's to notice that writing faster code was never going to be the thing that unstuck this, and go find out what actually would.
Field Mappings