More of What, Exactly?

A team builds a dashboard. The dashboard shows that churn went up 3%. Someone asks what to do about it. Nobody knows, because the dashboard only answers "what" — never "so what," and never "what did we try last time, what did we expect to happen, and did it work."

That feedback loop — what did we decide, what did we expect, what happened, what did we learn — doesn't exist at most analytics organizations. And right now, every exec in tech is saying AI lets us produce more of these dashboards, more of these reports, with fewer people.

More of what, exactly?

I know — me, a former tech lead and new engineering manager, arguing against headcount cuts has an obvious bias. But my argument isn't about preserving my career or fighting headcount reductions. It's "know why you're doing it."

A tale of two theories

There are two ways I've observed the industry talk about AI and engineering teams since the start of the year.

The first is adoption-driven: get your engineers using AI tools, track token usage, measure output. The theory is that if everyone adopts the tools, productivity follows. Companies are building dashboards to measure how much their teams use AI, which is ironic in ways I'll get to.

The second is headcount-driven: given the productivity boost, you can get the same output with fewer people. Companies like Meta and Block have reduced their staff in the name of AI. Their thesis: engineers augmented by AI produce 10x the output, so you need a tenth of the engineers.

Both approaches share a blind spot. They optimize for output — more code, more dashboards, more reports — without asking whether that output was the right thing to produce in the first place.

The output isn't the problem. What's underneath is.

AI can now generate a dashboard in seconds, auto-summarize a dataset, build a report with a prompt. But if there was no decision infrastructure underneath — no record of what the team decided, what they expected, and whether it worked — you've just made the proxy faster. (AKA, a jet engine on a treadmill.)

The best firms take this knowledge and democratize it into strategic documents like WBRs, QBRs, and other data-informed artifacts to guide the business. The dashboards were always a proxy for that deeper work. AI is stripping away the proxy, and what's left is either a real decision infrastructure or nothing at all.

Reduce your context at your own peril

AI output is only as good as the context you give it. Generic input produces generic output — the model defaults to the most common pattern in its training data and presents it as if it's the obvious conclusion. Without the context of what your business actually is, the model picks "generic consumer tech" and runs with it.

At most analytics organizations, that context lives in people's heads. The product manager who knows why a metric is defined the way it is. The analyst who remembers that the team tried a particular approach in Q2 and it failed because of a constraint nobody documented. The engineer who can look at a model's output and feel that something is off before they can articulate why.

The strongest version of the cut-first argument says AI can capture context itself — that the tools will systematize what used to live in people's heads. I'm skeptical — not because it's impossible, but because most analytics organizations haven't done the prerequisite work. You can't systematize knowledge you haven't identified. Systematizing context is the trillion-dollar idea.

But the sequencing matters: you have to build the context layer first, then optimize headcount.

If you cut without thinking about what you're cutting for, you run the risk of not capturing the value you think you're capturing.

Fire those people before that work is done and you didn't save money. You deleted the context layer that made everything downstream useful. You now have a very fast, very confident system defaulting to "generic" every time.

How we build

The thing I keep coming back to is that the value isn't in the model. It's not even in the harness around the model, though that matters enormously. The value is in three layers working together.

The context layer — the institutional knowledge, the business logic, the metric definitions, the decision history. Not just facts, but what we do with those facts. This is the layer that most analytics organizations never built, and it's the layer that makes every AI output downstream either specific and useful or generic and dangerous.

The judgment layer — the human capacity to look at output and know whether it's right. Not because you checked every line, but because you have enough experience and taste to feel when something is off. This is what Azeem Azhar calls the distinction between cognitive offloading — strategically delegating tasks that don't require your reasoning — and cognitive surrender, which is the uncritical abdication of reasoning itself.

Anthropic's own research on AI-assisted coding supports this: engineers who lean on AI without exercising their own judgment don't develop the skills they need to supervise it effectively. The risk isn't just individual skill atrophy — it's cognitive surrender at scale. If engineers just ship AI output without thinking critically about it, they don't grow. And if the people who remain aren't growing, you've traded a headcount problem for a capability problem.

The architecture — the harness, the systems, the feedback loops that connect context to judgment to output and back again. Even in coding, where feedback loops are clean and tests give you ground truth, a better environment produced 64% better results from the same model. In analytics, where the ground truth is ambiguous and the context lives in people's heads, the architecture matters even more.

The engineer role isn't shrinking. It's splitting. One path leads to factory operator — optimize throughput, manage the production line, eventually get automated yourself. The other leads to what I'd call a judgment architect — the person who builds the context layer, designs the decision infrastructure, and creates the systems that make both humans and agents effective.

A judgment architect doesn't just review dashboards. They build the metric governance that ensures every team is working from the same definitions. They design the decision review process. They create the feedback loop between what the team decided and what actually happened. They ship the system that turns institutional knowledge from something that walks out the door when someone leaves into something the entire organization can query and build on.

The goal isn't to never make a wrong choice. It's to recover faster from wrong choices, re-encode what you learned into the context and judgment layers, and let that drive better outcomes next time. That is the feedback loop that matters. Not "how many tokens did your team use today."

The companies that win won't confuse reducing headcount with AI improvement. They'll figure out what the remaining people should actually be doing.

And what they should be doing is building context, exercising judgment, and designing the architecture that makes AI useful — not just fast.