This week three articles survived my yellow highlights in my read wiseaccount. The first is “Are Data Teams Cooked?” by Joe Reis, the second “How Does AI Shape Teams Doing Knowledge Work?” by Matthew Skelton, and the third “Harness Engineering for Coding Agent Users” by Birgitta Böckeler on martinfowler.com so it’s a pretty heavy data Substack this week as that is what is on my mind.
1. Capability is not context.
Are Data Teams Cooked?
Joe Reis, Substack
Joe is spot on that some data work will be automated away. That’s real. We had these abstractions before. Spreadsheets were supposedly to kill booking, and yes it was true since 1980s 400,000 bookkeeping and accounting clerk jobs have gone away. But 600,000 accounting jobs have been added so a bit of a wash.
The data warehouse was supposed to make the DBA optional. We keep redesigning the container and arguing about the container, while the stuff inside, data modeling , making decisions, agreed-upon definitions keeps being the actual problem.
The picture isn’t shrinkage. It’s reallocation. The data team formally “reduces” but you find the same skills bumped into departments, sitting inside product or finance, doing the same work under a different org chart leaf folks that used to only use excel and some SQL now feel more empowered to go free-range. However, anyone in the data space knows that getting solid context is hard, and it requires people to sit in a “room” and agree on stuff. Agents inherit whatever agreement already exists. If there’s no agreement, they inherit the ambiguity.
The fancy tech doesn’t replace solid foundations – it makes them more important. If you already have the data team with clean models and documented contracts, you can x*y* their output. If your foundations are shaky, you’ve just got a faster mess. You could build the same agent-assisted workflow on top of HTML, JS, and a chat box if the data model is sound. The tool is rarely the bottleneck.
A lot of people are treating agent capability as organizational clarity. It isn’t. Claude workspace, is replaced by Grokbot then Muse, then XYZ, The agent needs context to work from. Context requires agreement. Agreement requires people doing the boring work of deciding what things mean and writing it down somewhere that isn’t one person’s memory then iterate as you learn more.
2. Don’t put AI on the org chart.
How Does AI Shape Teams Doing Knowledge Work?
Matthew Skelton, matthewskelton.com
Skelton is one of the Team Topologies authors, which means he thinks in domain boundaries and team interaction modes for a living. This post does something useful: it pulls the “hire an AI employee” conversation back into systems design language. His argument is that framing AI as workforce is a category error. Treat it as infrastructure. Make it the variable layer – bounded, purposeful, subordinate to human stewardship of value flow and it’s an interesting concept.
I’ve been thinking about it a lot these past months. There’s too much anthropomorphizing of these tools, yes AI is a tool. We give them names, argue about their “understanding,” write think-pieces about their “intentions.” Come on folks. They’re powerful tools that expose your org’s structural debt faster than most audits ever could. When you treat them like a workforce, you’re implicitly assuming they hold domain context by default. They don’t. They borrow it from whatever you’ve made explicit, and they magnify whatever you haven’t or get creative - people do this also, just not at AI speed.
This I think all connects directly back to Joe’s piece. Getting solid context is hard because most organizations never had to externalize it before, well we have all read the dead an useless project docs before. Skelton is describing the structural reason why: when you treat AI as workforce, you skip the step of making the context explicit. Which is where it should have been all along, and wasn’t and power to folks that are doing this work now inside of your business.
3. The harness is the job now
Birgitta Böckeler, martinfowler.com
Böckeler splits the feedback layer for agent-written code into two categories: computational sensors and inferential sensors.
Computational sensors are your tests, linters, type checkers thus deterministic, fast, cheap. They run in milliseconds and don’t hallucinate. Such as a schema check, a dbt test, a failing type annotation – those are computational sensors. You can actually trust them, because they’re the boring tooling we already have.
Inferential sensors are the AI-assisted code review layer: slower, non-deterministic, more expensive to run per cycle. Useful, but in a different register of reliability ( hint low).
Grading AI-written code with AI-written tests is marking your own homework - now I’m not an expert in the field and I do use tools like coder rabbit and roborev to help me guard against my agent slop. If the agent generates the function and generates the test suite, and the tests pass, you’ve confirmed internal consistency ( so please try and create your own tests with or least think through it). That’s it.
Remember they existed before agents arrived, they don’t care who wrote the code, and they’re cheap enough to run on every commit.
The thread I see
All three of these pieces are saying something adjacent to the same thing, starting from different directions.
Agents exposed the work we almost alway skip. Data modeling we deferred ( guilty). Domain boundaries we kept informal because everyone in the room already “knew” them. Tests we promised to write after the deadline passed. Governance “documents” that lived in one person’s head because that person had been there the longest and nobody ever pushed to extract it. Documentation that was “obvious” to anyone who’d attended the original meeting. None of this is new failure. AI/Agents just made it visible faster, and harder to ignore or lead you down the path of thinking it’s right.
If you learned the fundamentals the slow way, this is actually good news. The SQL fundamentals, the data modeling, the boring tests, the clear domain contracts – they didn’t get less valuable when agents arrived. They got more valuable. They became a base in a way that’s now hard to argue with. The plumber’s work is invisible until the pipe bursts. Right now there are a lot of pipes bursting, and the people who know how to fix them are doing fine which is good for senior engineers and above, not so great for apprenticeships and new grads.
For my own situation I’m also running several coding agents right now, and I do not have this figured out. My harness is patchy. most of my domain boundaries are informal. There’s context that lives in my head that probably should be written down somewhere an agent – or a new hire – could actually find it. I’m not writing this from a solved position. I’m writing it because I keep hitting the same wall from three different directions, and apparently so is everyone else I respect.
Unresolved. Like most things worth thinking about.
Reader question
How much context in your org actually lives somewhere an agent or a new hire could read?
And how much of it lives in people’s heads and Slack threads from years years ago?
Genuinely curious.
What did you read this week that survived the filter? Hit reply, I read everything.
I also write/podcast about raising four kids with my neuroscientist wife over at
Love the linkages between 2 and 1 here. Its something I've been thinking about a lot with org structure/ design and how that evolves with AI